◀ Prev · Parts · Full · Next ▶

When object-oriented language compilers were first being developed, much of the existing compiler technology was used, and objects were built on top of the record concept. In these languages the objects were referred to by their starting point, and their public data, known as "fields", were accessed through the known offset. In effect the only change was to add another field to the record, which is set to point to an immutable virtual method table for each class, such that the record describes both its data and methods (functions). When compiled, the offsets are used to access both the data and the code (via the virtual method table).

This leads to a problem in larger programs when they are constructed from libraries. If the author of the library changes the size or layout of the public fields within the object, the offsets are now invalid and the program will no longer work. This is the FBI problem.

Although changes in implementation may be expected to cause problems, the insidious thing about FBI is that nothing really changed, only the layout of the object that is hidden in a compiled library. One might expect that if one changes doSomething to doSomethingElse that it might cause a problem, but in this case one can cause problems without changing doSomething, it can be caused as easily as moving lines of source code around for clarity. Worse, the programmer has little or no control over the resulting layout generated by the compiler, making this problem almost completely hidden from view.

◀ Prev · Parts · Full · Next ▶